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REMARKS 

Claims 1-34 were pending at the time of examination. No claims have been cancelled. 
The line numbering recommended by the Examiner has been added to the claims. The applicants 
respectfully request reconsideration based on the foregoing amendments and these remarks. 

Objections to the Specification 

The Examiner objected to the specification because of the use of various trademarks. 
The applicants have identified all the occurrences of proper names, and concluded that none of 
them is used in connection with any specific products. Thus, the proper names not used in a 
trademark fashion, but are rather used as names of providers of various products, in which case 
they do not need to have the ™ symbol attached to their names. Nevertheless, as the suppliers 
do need to be uniquely identified, the applicants have amended the specification to add the full 
names and locations of the companies that are mentioned in the specification, 

The applicants believe that the specification is now in allowable form and submit that the 
objections to the specification be removed. 

Claim Rejections - 35 ILS.C. § 102 

Claims 1-34 are rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent 
Application Publication No. US 2003/0058277 Al to Bowman-Amuah et al. (hereinafter 
Bowman). The applicants respectfully traverse the rejection for the following reasons. 

The applicants' invention relates to a message routing network for routing messages 
between applications. More particularly, the interchange of enterprise data is supported through 
an open platform for enterprise application integration (EAI). This open platform overlays a 
public network, such as the Internet, and does not require business entities to heavily invest in 
specialized software and resources. Thus, the invention enables the provision of extra-enterprise 
application integration as a service. This service facilitates EAI efficiently and affordably. More 
generally, the message routing network of the present invention can be used to support services 
provided by business-to-business enablers, system integrators, and other node enablers 
(Specification, paragraph [1081]). 

Bowman, on the other hand, is directed to a view configurer in a presentation services 
patterns environment, which assigns a view to a particular activity. A notification is received 
that a startup event of an activity has occurred. A reference to a first instance of an object 
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created by the startup event of the activity is also received. When the notification and the 
reference have been received, a view to launch is determined based on predetermined criteria, 
which may Include user preferences, an experience level of a user, security profiles, and/or 
workflow settings, The view is associated with the activity and displayed. Alternatively, the 
activity can run without a corresponding view. The activity can operate on a machine separate 
from a machine of an end user (Bowman, paragraphs [0009]-[0010]), 

Turning now to the Specific rejections of the claims, claim 1 recites: 

"invoking a second service during said logical routing of said message in said 
message routing network, said second service invocation having a second context 
that is defined at least in part by said first service" 

That is* the second service is invoked during the Iogical_ronting of the message, 
Furthermore, the first service defines at least part of the context for the second service . The 
context can include, for example, an identity of the invoker service, arguments to the invoked 
service, a session identifier for a message, a topic for a message, a billing responsibility for the 
invocation, or any other information that can be used by the invoked service (Specification, 
paragraph [1097]). The Examiner rejected this step referring to Bowman paragraphs [0164], 
[3346], [3635), [3S21], [3814], [3829], and [3836-3837], respectively, adding that Bowman 
discusses remote method invocation (RMI), and that in the cited sections of Bowman. 

"a single work unit has the possibility of involving multiple invocations on 
another node wherein the invocations are interrelated towards a particular task but 
involving different contexts." 

Paragraph [0164] of Bowman refers to FIG. 152, which shows "a flowchart for a method 
for maintaining a security profile throughout nested service invocations on distributed 
components/ 1 FIG. 152 is described in further detail in paragraph [4128] of Bowman, The 
applicants acknowledge that step 15210 of FIG. 152 shows that a request is received from the 
user to invoke a service on a component, and that the component in turn invokes an additional 
service of another component However, the above claim limitation requires that "said second 
service invocation having a second context that is Refined at least in part by said first service ." 
In Bowman, the initiating service does not define any context. The purpose of Bowman is 
"maintaining a security profile throughout nested service invocations on distributed 
components." Thus, in Bowman, there is no need to define a second context (or part of a second 
context), since the goal is simply to maintain, a security profile throughout the nested service 
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invocations. Instead, the first service merely queries the "user context" for information about the 
user (step 1 5212), The obtained user information is then compared with an access control list for 
verifying that the user has access to the component in operation (that is, the "first service" in the 
applicants' terminology) (step 15214). The user information is also compared with an access 
control list for verifying that the user has access to the additional service of the other component 
in operation (that is, the "second service** in the applicants' terminology) (step 15216). 

Paragraph [3346] of Bowman states that Object Request Brokers (ORJBs) that use 
CORBA, DCOM, or Java RMI define an interface definition language (IDL) that is the format or 
contract of a stream and use stream-based communication as the communication medium. 
Streaming is a particular type of process for transferring time-sensitive data streams (e.g. video 
and/or audio) in real-time (see, for example, Bowman paragraph [1255)). Streaming (or any 
other method of transferring real-time data) is not recited anywhere in claim 1 . 

Paragraph [3635] of Bowman discusses how a Globally Addressable Interface (GAT), 

which is retrieved by a client from a naming or Trader service, passes through three phases: 

"Initial retrieval of a GAI from the Trader Service that is subsequently wrapped 
up in a proxy, 2) Invocations of businesses functions supported by the GAI and 3) 
Release of the GAI proxy. This often means a long-lived client will repeatedly ask 
the Trader Service for the same type of interface during its lifetime." 

The fact that a GAI goes through three phases does not bear any significance with respect 
to the claimed limitation of a first service defining at least part of a context for a second service 
during the routing of a message through a message routing network. At the very least, the 
applicants would appreciate an explanation from the Examiner as to how this paragraph could 
anticipate or render obvious the claimed limitations. 

Paragraph [3821] of Bowman states that a 

"... client may need to interact with a number of server components. From the 
user's perspective, one unit of work is being performed but it may involve 
multiple, discrete interfaces and multiple server invocations. Some business logic 
is required to manage the complex flow to complete this unit of work... 
Managing this flow is not the responsibility of the presentation logic but still 
needs to be executed on the client" 

As was discussed above with respect to paragraph [0164] it is true that several server 
components or services may be involved in carrying out "one unit of work." In Bowman, the 
business logic for managing the flow is executed on the client In the applicants' invention, on 
the other hand, the second service is not invoked by the client, but instead bv the first service . 
The first service also defines at least part of the context for the second invocation. There is no 
discussion of contexts in this cited section of Bowman. Even if contexts were discussed, it 
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would be reasonable to assume that the business logic operating on the client is responsible for 
defining the context of the various server components with which the client interacts - not the 
first service, as required by claim 1 . 

Paragraph [3814] of Bowman provides an overview of a set of patterns designed to help 
"to guide application architects on strong, proves techniques to safely integrate client-side 
business logic with an application's Presentation Services " According to Bowman, an Activity 
pattern lays the groundwork for separating the Presentation Services and business logic on the 
client by assigning non-presentation logic to a type of object called an Activity, A View 
Configurer pattern helps to assign new views with their appropriate Activity. Finally, a User 
Interface Validator pattern describes how to implement customizable, extendable validation logic 
on a user interface. The applicants would like to point out that all of these "patterns" relate to 
various aspects of presenting data to a user, and none of them describe how services are invoked 
or any contexts that are associated with invoking services. Claim 1 is directed to a message 
routing method — not to a method of presenting data. The applicants respectfully request an 
explanation from the Examiner of how the subject matter disclosed in paragraph [3814] of 
Bowman possibly could anticipate any limitations of claim 1. 

Paragraph [3329] of Bowman refers to the benefits of a "Fixed Format Stream Pattern" 
disclosed in FIG. 68 of Bowman. In the Fixed Format Stream pattern, a data structure on a first 
system is translated to a Fixed Format message (raw data) usiag a Fixed Format contract. The 
message is put in a stream and sent to a second system. The second system receives the Fixed 
Format Message (raw data) and uses its Fixed Format contract to recreate the data structure. The 
same process works in reverse when the second system responds to the message request 
(Bowman, paragraph [3327]). According to the cited paragraph [3329] one benefit with the 
Fixed Format Stream pattern is that the performance is better than with other variations of 
Stream-Based Communication since there is no time spent on look-ups or dynamic translation of 
the message. Again, streaming is a particular type of process for transferring time-sensitive 
data streams (e.g. video and/or audio) in real-time, and is not recited or implied anywhere in 
claim 1. 

Paragraphs 13836-3837] of Bowman refer to FIG. 125, which is an activity entity 
relationship diagram that shows how an Activity resides between the actual user interface and the 
business model and server components. As a result, multiple types of interfaces can exist on a 
single type of Activity, code can be reused, and no code will be lost if the presentation logic is 
replaced. A user interface can communicate directly with its associated activity, but an activity 
cannot directly communicate with any of its interfaces. Instead, an activity can communicate to 
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its interfaces through an event mechanism. Interfaces are set up as dependents of the activity and 

the activity sends events to all of the interfaces on it Each interface can decide how to handle 

the event. Again, all the subject matter presented in paragraphs [3836-3837] of Bowman is 

directed to various aspects of presenting data. Nowhere in the cited paragraphs is it mentioned 

how services are invoked or any contexts that are associated with invoicing services. Claim 1 is 

directed to a message routing method — not to a method of presenting data, and can thus not be 

anticipated by the subject matter in paragraphs [3836-3837] of Bowman. 

The applicants respectfully submit that none of these cited paragraphs, alone or in 

combination, can reasonably teach or suggest the subject matter recited in claim 1. The 

Examiners statement that 

"In the sections cited in Bowman, a single work unit has the possibility of 
involving multiple invocations on another node in the network wherein the 
invocations are interrelated towards a particular task but involving various 
contexts." 

may be correct, but from the discussion above it ought to be clear that this is not what is 
claimed in claim 1. For at least these reasons the rejection of claim 1 is unsupported by the art 
and should be withdrawn. 

Claims 2-12 all depend from claim 1, and are therefore neither anticipated nor obvious 
for at least the reasons discussed above with respect to claim 1, and the rejections of claims 2-12 
should be withdrawn. 

Claim 13 is a Beauregard claim corresponding to claim 1, and is therefore neither 
anticipated nor obvious for at least the reasons discussed above with respect to claim 1, and the 
rejection of claim 13 should be withdrawn. 

Claim 14 is a system claim with limitations similar to the limitations of claim 1, and was 
rejected with the same rationale as claim 1, along with paragraphs [4317-4318] of Bowman. 
These additional paragraphs of Bowman discuss how object identifiers are stored in order to 
provide object persistence for business objects. Neither claim 14 nor claim 1 contains any 
limitations reciting object identifiers or object persistence. Claim 14 is therefore neither 
anticipated nor obvious for at least the reasons discussed above with respect to claim 1, and the 
rejection of claim 14 should be withdrawn. 

Claims 15-27 all depend from claim 14, and are therefore neither anticipated nor obvious 
for at least the reasons discussed above with respect to claim 14, and the rejections of claims 15- 
27 should be withdrawn. 
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Claim 28 is a method claim directed to a message routing method. Steps (b) and (c) are 
similar to the limitations of claim 1, and were rejected for the same reasons as claim 1 , Step (a) 
recites: 

"invoking a first service that receives only logical delivery of an application 
message, said application message received over a public network, wherein said 
first service invocation has a first context defined at least in part by a first 
invoking service;" 

The Examiner rejected this step referring to Bowman paragraphs [3157], [3199], [3287], 
and (1077], respectively. Paragraph [3157] states that "A set of logical operations may need to 
be initiated through some 'batch' scheduling means..," Paragraph [3199] discusses how filters 
consume and deliver their results incrementally, rather than consuming all of their input before 
producing output, and the benefits of using filters in terms of system scalability. Paragraph 
[3287] discusses how named constants in programming languages can belong to logical 
groupings, for example, how the constants STOCK, BOND, and OPTION are all types of 
financial instruments. Finally, paragraph [1077] discusses how a directory service "organizes, 
categorizes and names networked resources in order to provide a comprehensive picture of 
clients, servers, users, applications and other resources." The applicants respectfully submit that 
none of these cited paragraphs anticipate or render obvious the claimed limitation of "invoking a 
first service that receives only logical delivery of an application message' 7 and that "said first 
service invocation has a first context defined at least in part bv the first involdng^saGdce /' Even 
if one were to equate the "batch scheduling means" of paragraph [3157] with "a first invoking 
service," as the Examiner appears to have done, none of the cited paragraphs would show how 
the first context is defined at least in part by the first invoking service (or the actual service 
invocation of the first service for that matter). 

Steps (b) and (c) of claim 28 are neither anticipated nor obvious for at least the reasons 
discussed above with respect to claim L Thus, the applicants therefore respectfully submit that 
the rejection of claim 28 be withdrawn. 

Claims 29-34 all depend from claim 28, and are therefore neither anticipated nor obvious 
for at least the reasons discussed above with respect to claim 28, and the rejections of claims 29- 
34 should be withdrawn. 
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Conclusion 

The applicants believe that all pending claims are allowable and respectfully request a 
Notice of Allowance for this application from the Examiner. Should the Examiner believe that a 
telephone conference would expedite the prosecution of this application, the undersigned can be 
reached at the telephone number set out below. 



Respectfully submitted, 

BEYER WEAVER & THOMAS, LLP 

Fredrik Mollbom 
Reg. No, 48,587 

P.O. Box 778 

Berkeley, CA 94704-0778 
(650) 961-8300 
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